home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
internet-drafts
/
draft-ietf-frnetmib-fr-00.txt
< prev
next >
Wrap
Text File
|
1993-06-07
|
68KB
|
2,301 lines
Internet Draft Frame Relay Service MIB May 12, 1993
Definitions of Managed Objects
for Frame Relay Service
May 12, 1993
Frame Relay Service MIB Working Group
Tracy A. Cox (editor)
Bell Communications Research
331 Newman Springs Road
Red Bank, NJ 07701
tacox@mail.bellcore.com
1. Status of this Memo
This document is an Internet Draft. Internet Drafts are
working documents of the Internet Engineering Task Force
(IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted
by other documents at any time. It is not appropriate to use
Internet Drafts as reference material or to cite them other
than as a "working draft" or "work in progress."
Please check the I-D abstract listing contained in each
Internet Draft directory to learn the current status of this
or any other Internet Draft.
2. Abstract
This memo defines an extension to the Management Information
Base (MIB) for use with network management protocols in
TCP/IP-based internets. In particular, it defines objects for
managing the Frame Relay Service.
This memo does not specify a standard for the Internet
community.
T. Cox (editor) Expires 12/31/93 [Page 1]
Internet Draft Frame Relay Service MIB May 12, 1993
3. The Network Management Framework
The Internet-standard Network Management Framework consists of three
components. They are:
RFC 1155 which defines the SMI, the mechanisms used for describing
and naming objects for the purpose of management. RFC 1212
defines a more concise description mechanism, which is wholly
consistent with the SMI.
RFC 1156 which defines MIB-I, the core set of managed objects for
the Internet suite of protocols. RFC 1213, defines MIB-II, an
evolution of MIB-I based on implementation experience and new
operational requirements.
RFC 1157 which defines the SNMP, the protocol used for network
access to managed objects.
The Framework permits new objects to be defined for the purpose of
experimentation and evaluation.
T. Cox (editor) Expires 12/31/93 [Page 2]
Internet Draft Frame Relay Service MIB May 12, 1993
4. Objects
Managed objects are accessed via a virtual information store,
termed the Management Information Base or MIB. Objects in the
MIB are defined using the subset of Abstract Syntax Notation
One (ASN.1) [7] defined in the SMI. In particular, each
object has a name, a syntax, and an encoding. The name is an
object identifier, an administratively assigned name, which
specifies an object type. The object type together with an
object instance serves to uniquely identify a specific
instantiation of the object. For human convenience, we often
use a textual string, termed the OBJECT DESCRIPTOR, to also
refer to the object type.
The syntax of an object type defines the abstract data
structure corresponding to that object type. The ASN.1
language is used for this purpose. However, the SMI [3]
purposely restricts the ASN.1 constructs which may be used.
These restrictions are explicitly made for simplicity.
The encoding of an object type is simply how that object type
is represented using the object type's syntax. Implicitly
tied to the notion of an object type's syntax and encoding is
how the object type is represented when being transmitted on
the network. The SMI specifies the use of the basic encoding
rules of ASN.1 [8], subject to the additional requirements
imposed by the SNMP.
4.1. Format of Definitions
Section 6 contains contains the specification of all object
types contained in this MIB module. The object types are
defined using the conventions defined in the SMI, as amended
by the extensions specified in RFC1212 [9].
T. Cox (editor) Expires 12/31/93 [Page 3]
Internet Draft Frame Relay Service MIB May 12, 1993
5. Overview
These objects are used when the particular media being used to
managed Frame Relay Service. At present, this applies to
these values of the ifType variable in the Internet-standard
MIB:
frame-relay (32)
This section provides an overview and background of how to use
this MIB and other potential MIBs when managing a Frame Relay
Service.
The following diagram shows the MIB stack that could be
followed for managing a Frame Relay Service. This is only an
example and not meant to be inclusive.
_____________________________________
| |
| MIB II |
|___________________________________|
| | | |
| Frame Relay | SIP | RFC1294 |
| X.25 MIB | Relay | (no applic.|
| for IW/Encap.| MIB | MIB) |
| | | |
|-----------------------------------|
| |
| Frame Relay Service MIB |
|___________________________________|
| | |
| Physical Layer MIBs | ATM MIB |
| e.g., DS1/E1 MIB, |---------|
| RS232-like MIB | Phy. |
| | Layer |
| | MIB |
|-------------------------|---------|
SCOPE OF MIB:
The Frame Relay Service MIB will only manage the Frame Relay
portion of the network and will provide a pointer to the lower
layer MIB (for example, a physical layer MIB or the ATM MIB)
for each UNI/NNI access channel.
This MIB will NOT be implemented on User Equipment.
T. Cox (editor) Expires 12/31/93 [Page 4]
Internet Draft Frame Relay Service MIB May 12, 1993
Frame Relay Service SNMP MIB for Customer Network Management
(CNM) is an SNMPv1 MIB. It provides read-only information
that allows end-customers to obtain performance monitoring,
fault detection, and to obtain performance monitoring, fault
detection, and configuration information about their Frame
Relay Service. By using this and other related MIBs, a
customer's NMS can monitor their PVCs and UNI/NNI access
channels. Internal aspects of the network (e.g., switching
elements, line cards, and network routing tables) are outside
the scope of this MIB. The Customer's NMS will be able to
access the SNMP agent within the Frame Relay network using
SNMP over UDP over IP with IP encapsulated in Frame Relay
according to RFC1294/ANSI T1.617 Annex F. The customer thus
has a PVC to the SNMP agent. Alternate access mechanisms are
possible. The initial implementation of the MIB is based on
SNMPv1. The service capabilities include retrieving
information and receiving TRAPs. It is beyond the scope of
this MIB to define managed objects to monitor the physical
layer. Existing physical layer MIBs (e.g., DS1 MIB) and MIB
II will be used as possible. The Frame Relay Service SNMP MIB
for CNM will not contain any managed objects to monitor the
physical layer. However, the Frame Relay Service SNMP MIB for
CNM will contain a pointer to the appropriate lower layer MIB
for each UNI/NNI access channel. To the maximum extent as
possible, PVCs and SVCs will be treated equally in the MIB.
The Frame Relay Service MIB will only manage the Frame Relay
portion of the network and will provide a pointer to the lower
layer MIB (for example, a physical layer MIB or the ATM MIB)
for each UNI/NNI access channel.
5.1. Apply MIB II to a Frame Relay Service
Use the System Group to apply to the SNMP agent/proxy-agent,
since the agent/proxy-agent may be monitoring many Frame Relay
devices in one network. System Group applies to only one
system. This group is not instantiated.
sysDescr: ascii string describing the SNMP agent/proxy-agent.
can be only up to 255 characters long.
sysObjectID: unique OID for the SNMP agent/proxy-agent.
sysUpTime: clock in the SNMP agent/proxy-agent; TimeTicks
T. Cox (editor) Expires 12/31/93 [Page 5]
Internet Draft Frame Relay Service MIB May 12, 1993
in 1/100s of a seconds
sysContact: Contact for the SNMP agent/proxy-agent
ascii string of up to 255 characters
sysName: Domain name of the SNMP agent/proxy-agent, for example,
mail.bellcore.com
sysLocation: Location of the SNMP agent/proxy-agent
ascii string of up to 255 characters
sysServices: services of the managed device; suggest
using the value "2" which implies that
the Frame Relay service is providing
a subnetwork level service
Use the Interface Group to apply to the FR-UNIs and the FR-
NNIs of the Frame Relay service. This group is instantiated
by ifIndex.
ifIndex: unique identifier for the UNI/NNI access channel
ifDescr: ascii string describing the UNI/NNI access channel,
can be only up to 255 characters long.
ifType: identifies the service below the network layer and is used
to identify the MIB below MIB II as shown in the figure
above.
"32" for frame-relay
ifMtu: size of largest SDU size for frame-relay for
this UNI/NNI access channel, e.g., "1600"
ifSpeed: actual user information transfer rate of the UNI/NNI
access channel in bits per second
e.g., 1536000 bits per second for a DS1-based FR-UNI
and 1948000 bits per second for an E1-based FR-UNI.
ifAdminStatus: the administrative status of the UNI/NNI access channel
ifOperStatus: the operational status of the UNI/NNI access channel
ifLastChange: Timestamp of the last time something
changed on the UNI/NNI access channel
T. Cox (editor) Expires 12/31/93 [Page 6]
Internet Draft Frame Relay Service MIB May 12, 1993
ifSpecific: OID pointing to the top of the Frame Relay
Service MIB
5.2. Apply the DS1/E1 MIB to Frame Relay Service
Use the DS1/E1 MIB (RFC1406) to manage DS1/E1 UNI/NNI access
channels.
The ifIndex value from the UNI/NNI access channels group will
be used to identify the Frame Relay network UNI/NNI access channel.
For a Frame Relay DS1/E1
or DS3/E3 UNI/NNI access channel (either FR-UNI or
FR-NNI):
ifIndex = dsx1LineIndex = dsx1IfIndex
ifIndex = dsx3LineIndex = dsx1IfIndex
mandatory groups are:
dsx1ConfigTable
dsx1CurrentTable
dsx1IntervalTable
dsx1TotalTable
optional groups are:
dsx1FarEndCurrentTable
dsx1FarEndIntervalTable
dsx1FarEndTotalTable
If the T1/E1 UNI/NNI access channel supports fractional subrates
then the dsx1FracTable should be supported
to identify the channels within the T1/E1 line.
The indices are as follows:
In this case ifIndex does not equal dsx1LineIndex
BUT:
dsx1LineIndex = dsx1FracIndex
ifIndex = dsx1FracIfIndex
dsx1IfIndex is not used (noSuchName)
T. Cox (editor) Expires 12/31/93 [Page 7]
Internet Draft Frame Relay Service MIB May 12, 1993
The following provides an example of how the indexing works
for the DS1 MIB and MIB II:
For example:
A Frame Relay Switch has three DS1 interfaces:
DS1 Line 1 has 3 channels defined,
Channel 1 uses timeslots 1-2,
Channel 2 uses timeslots 3-5,
Channel 3 uses timeslots 6-7,
Remaining timeslots unused.
DS1 Line 2 has 2 channels defined,
Channel 1 uses timeslots 1-3,
Channel 2 uses timeslots 4-7,
Remaining timeslots unused.
DS1 Line 3 has 1 channel defined,
Channel 1 uses timeslots 1-24,
All timeslots used.
You have 3 DS1 interfaces off the frame relay network. You also
have 6 access channels that are distributed across those 3 interfaces.
Those six access channels map to an ifIndex value in MIB II.
Each channel should have:
ifIndex = 1; ifType = frame-relay
ifIndex = 2; ifType = frame-relay
ifIndex = 3; ifType = frame-relay
ifIndex = 4; ifType = frame-relay
ifIndex = 5; ifType = frame-relay
ifIndex = 6; ifType = frame-relay
(and the other applicable ifTable information)
Next, Line 1 and 2 are fractional interfaces, whereas, Line 3
is not.
Therefore, let's start with what is called Line 3.
DS1 Line 3 has 1 channel defined,
Channel 1 uses timeslots 1-24,
All timeslots used.
From RFC1406,
T. Cox (editor) Expires 12/31/93 [Page 8]
Internet Draft Frame Relay Service MIB May 12, 1993
(let's ignore RFC1406 Section 3.1, because
for the case where the router proxies for the CSU and you
would want to manage both internal (router side) and external
(network side) DS1 interfaces),
for Line 3:
dsx1LineIndex = dsx1IfIndex = ifIndex = 1
for this interface the fractional table is not supported, and there is
a one-to-one correspondence between a DS1 Line and an access channel.
Looking at the example and the dsx1ConfigTable,
this table is not very "friendly" for fractional DS1 interfaces.
For fractional DS1 interfaces, there is NOT a 1-to-1 relationship
between an ifIndex value ( = dsx1IfIndex) and dsx1LineIndex, but
the table forces there to be one. Rightly so because,
the table should
only be used to manage DS1 interfaces once.
But what to do when you have multiple ifIndices for that
one dsx1LineIndex? I suggest return noSuchName for
dsx1IfIndex when supporting a fractional T1 interface.
Remember dsx1IfIndex = ifIndex always.
Line 1 and Line 2 support fractional interfaces.
By reading the description of dsx1LineIndex in the dsx1ConfigTable:
"This object is the identifier of a DS1/E1
Interface on a managed device. If there is an
ifEntry that is directly associated with this
and only this DS1/E1 interface, it should have
the same value as ifIndex. Otherwise, number
the dsx1LineIndices with an unique identifier
following the rules of choosing a number that
is greater than ifNumber and numbering the
inside interfaces (e.g., equipment side) with
even numbers and outside interfaces (e.g,
network side) with odd numbers."
Therefore, using this rule,
the DS1 lines can be labeled the following way:
Line 1 => dsx1LineIndex = 7
Line 2 => dsx1LineIndex = 9 (because they do not correspond
with one and only one ifIndex.)
T. Cox (editor) Expires 12/31/93 [Page 9]
Internet Draft Frame Relay Service MIB May 12, 1993
Remember that this is only
an index and is not used for anything else but to index the
DS1 line and it is NOT equal to ifIndex for this case.
for these two cases; dsx1LineIndex =7 and 9;
(Remember for these two cases
dsx1IfIndex.7 = noSuchName and dsx1IfIndex.9 = noSuchName)
therefore go to fracTable:
dsx1FracIndex = dsx1LineIndex always
Line 1 has 3 channels defined,
Channel 1 uses timeslots 1-2,
Channel 2 uses timeslots 3-5,
Channel 3 uses timeslots 6-7,
Remaining timeslots unused.
dsx1LineIndex=7
dsx1FracIfIndex.7.1=2 (ifIndex=2)
dsx1FracIfIndex.7.2=2
dsx1FracIfIndex.7.3=3 (ifIndex=3)
dsx1FracIfIndex.7.4=3
dsx1FracIfIndex.7.5=3
dsx1FracIfIndex.7.6=4 (ifIndex=4)
dsx1FracIfIndex.7.7=4
I think the description of dsx1FracIfIndex is wrong when
it says "If no interface is currently using a channel, the
value should be zero."
But, because dsx1FracIfIndex is defined
as INTEGER (1..'7fffffff'h)
^
you can NOT have an Index = 0; I would say return noSuchName
for dsx1FracIfIndex.7.8 through dsx1FracIfIndex.7.24
Next:
Line 2 has 2 channels defined,
Channel 1 uses timeslots 1-3,
Channel 2 uses timeslots 4-7,
Remaining timeslots unused.
dsx1LineIndex=9
dsx1FracIfIndex.9.1=5 (ifIndex=5)
T. Cox (editor) Expires 12/31/93 [Page 10]
Internet Draft Frame Relay Service MIB May 12, 1993
dsx1FracIfIndex.9.2=5
dsx1FracIfIndex.9.3=5
dsx1FracIfIndex.9.4=6 (ifIndex=6)
dsx1FracIfIndex.9.5=6
dsx1FracIfIndex.9.6=6
dsx1FracIfIndex.9.7=7
again: I would say return noSuchName
for dsx1FracIfIndex.9.8 through dsx1FracIfIndex.9.24
5.3. Frame Relay Service MIB Terminology
Backward - Backward direction data traffic is traffic flowing
from the terminating access channel to the originating access
channel. This is illustrated in Figure 2.
Access Channel - An access channel generically refers to the
UNI access channel or NNI access channel across which frame
relay data transmits. An access channel is the access pathway
for a single stream of user data.
Within a given T1 line, an access channel can denote any one
of the following:
o Unchannelized T1 - the entire T1 line is considered an access
channel. Each access channel is comprised of 24 T1 time slots.
o Channelized T1 - an access channel is any one of 24 channels.
Each access channel is comprised of a single T1 time slot.
o Fractional T1 - an access channel is a grouping of N T1 time
slots (NX56/64 Kbps, where N = 1-23 T1 Time slots per FT1 Access
Channel) that may be assigned in consecutive or non-consecutive
order.
Within a given E1 line, a channel can denote any one of the following:
o Unchannelized E1 - the entire E1 line is considered a single
access channel. Each access channel is comprised of 31 E1 time
slots.
o Channelized E1 - an access channel is any one of 31 channels.
Each access channel is comprised of a single E1 time slot.
T. Cox (editor) Expires 12/31/93 [Page 11]
Internet Draft Frame Relay Service MIB May 12, 1993
o Fractional E1 - an access channel is a grouping of N E1 time
slots (NX64 Kbps, where N = 1-30 E1 time slots per FE1 access
channel) that may be assigned in consecutive or non-consecutive
order.
Within a given unformatted line, the entire unformatted line
is considered an access channel. Examples include RS-232,
V.35, V.36 and X.21 (non- switched).
Forward - Forward direction data traffic is traffic flowing
from the originating access channel to the terminating access
channel. This is illustrated in Figure 2.
Originating - Originating refers to the access channel from
which the virtual connection is initiated. In a multi-network
PVC, each PVC segment has an originating access channel and
terminating access channel for each network that the multi-
network PVC traverses. See Figure 1.
Permanent Virtual Connection (PVC) - A virtual connection that
has its endpoints and bearer capabilities defined at
subscription time.
Terminating - Terminating refers to the access channel at
which the virtual connection stops. In a multi-network PVC,
each PVC segment has an originating access channel and
terminating access channel for each network that the multi-
network PVC traverses. See Figure 1.
Time slot (E1) - An octet within the 256-bit information field
in each E1 frame is defined as a time slot. Time slots are
position sensitive within the 256-bit information field.
Fractional E1 service is provided in contiguous or non-
contiguous time slot increments.
Time slot (T1) - An octet within the 192-bit information field
in each T1 frame is defined as a time slot. Time slots are
position sensitive within the 192-bit information field.
Fractional T1 service is provided in contiguous or non-
contiguous time slot increments.
T. Cox (editor) Expires 12/31/93 [Page 12]
Internet Draft Frame Relay Service MIB May 12, 1993
UNI NNI NNI UNI
| | | |
| | | |
| PVC Segment 1 | PVC Segment 2 | PVC Segment 3 |
|<------------->|<------------->|<------------->|
| | | |
| +-----------+ | +-----------+ | +-----------+ |
| | | | | | | | | |
Originating | | | | | | | | | |Terminating
+--------+ | | Network I | | | Network J | | | Network K | | +--------+
| | | | | | | | | | | | | |
| User A | | | | | | | | | | | | |
| |----| |---| |---| |----| User B |
| | | | O T | | | O T | | | O T | | | |
| ////////////////////////////////////////////////////////////// |
| | | | | | | | | | | | | |
+--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
| | | |
| |
| Multi-network PVC |
|<------------------------------------------->|
| NNI = Network-to Network Interface |
| UNI = User-to-Network Interface
Figure 1
Multi-network PVC
T. Cox (editor) Expires 12/31/93 [Page 13]
Internet Draft Frame Relay Service MIB May 12, 1993
UNI UNI
| |
| |
| CIR-fwd, Bc-fwd, Be-fwd |
|--------------------------------------------->>|
| NNI NNI |
| +-----------+ | +-----------+ | +-----------+ |
| | | | | | | | | |
Originating | | | | | | | | | |Terminating
+--------+ | | Network I | | | Network J | | | Network K | | +--------+
| | | | | | | | | | | | | |
| User A | | | | | | | | | | | | |
| |----| |---| |---| |----| User B |
| | | | O T | | | O T | | | O T | | | |
| ////////////////////////////////////////////////////////////// |
| | | | | | | | | | | | | |
+--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
| | | |
| |
| CIR-bwd, Bc-bwd, Be-bwd |
|<<---------------------------------------------|
Figure 2
A Multi-network PVC
T. Cox (editor) Expires 12/31/93 [Page 14]
Internet Draft Frame Relay Service MIB May 12, 1993
+-------------------------------------+
| Customer Network Management Station |
| (SNMP based) |
+-------------------------------------+
/| /| /|
| | |
UNI / NNI / NNI / UNI
| +-----------+ | +-----------+ | +-----------+ |
| | | | | | | | | |
Originating | | | | | | | | | |Terminating
+--------+ | | Network I | | | Network J | | | Network K | | +--------+
| | | | | | | | | | | | | |
| User A | | | | | | | | | | | | |
| |----| |---| |---| |----| User B |
| | | | O T | | | O T | | | O T | | | |
| ////////////////////////////////////////////////////////////// |
| | | | | | | | | | | | | |
+--------+ | +-----------+ | +-----------+ | +-----------+ | +--------+
| | | |
Figure 3
Managing a Multi-network PVC
T. Cox (editor) Expires 12/31/93 [Page 15]
Internet Draft Frame Relay Service MIB May 12, 1993
6. Object Definitions
RFCxxxx-MIB DEFINITIONS ::= BEGIN
IMPORTS
experimental, Counter
FROM RFC1155-SMI
DisplayString
FROM RFC1213-MIB
OBJECT-TYPE
FROM RFC-1212;
-- This MIB module uses the extended OBJECT-TYPE macro as
-- defined in RFC 1212.
frnetserv OBJECT IDENTIFIER ::= { experimental 45 }
T. Cox (editor) Expires 12/31/93 [Page 16]
Internet Draft Frame Relay Service MIB May 12, 1993
-- The Frame Relay Service Channel Group
-- Implementation of this group is mandatory for all systems
-- that perform Frame Relay Services.
-- This group has two tables:
-- Frame Relay Channel Information
-- Frame Relay Channel Errors
-- the Frame Relay Channel Information
frChanTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrChanEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The Frame Relay Channel Information table."
::= { frnetserv 1 }
frChanEntry OBJECT-TYPE
SYNTAX FrChanEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the Frame Relay Channel Information
table."
INDEX { frChanIfIndex }
::= { frChanTable 1 }
FrChanEntry ::=
SEQUENCE {
frChanIfIndex
INTEGER,
frChanNumPlan
INTEGER,
frChanNetAddress
OCTET STRING,
frChanContact
DisplayString,
frChanLocation
DisplayString,
frChanIfType
INTEGER,
frChanIfSpecific
T. Cox (editor) Expires 12/31/93 [Page 17]
Internet Draft Frame Relay Service MIB May 12, 1993
OBJECT IDENTIFIER,
frChanQ922AddLen
INTEGER,
frChanDLCILen
INTEGER,
frChanSigState
INTEGER,
frChanSigProced
INTEGER,
frChanSigUserN391
INTEGER,
frChanSigUserN392
INTEGER,
frChanSigUserN393
INTEGER,
frChanSigUserT391
INTEGER,
frChanSigNetN392
INTEGER,
frChanSigNetN393
INTEGER,
frChanSigNetT392
INTEGER,
frChanSigNetnN4
INTEGER,
frChanSigNetnT3
INTEGER
}
frChanIfIndex OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to MIB II's
ifIndex value for this UNI/NNI access channel."
::= { frChanEntry 1 }
frChanNumPlan OBJECT-TYPE
SYNTAX INTEGER {
e164(1),
x121(2),
other(3)
}
ACCESS read-only
T. Cox (editor) Expires 12/31/93 [Page 18]
Internet Draft Frame Relay Service MIB May 12, 1993
STATUS mandatory
DESCRIPTION
"The value of this object identifies the numbering
plan that is used to identify the UNI/NNI access
channel."
::= { frChanEntry 2 }
frChanNetAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..8))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the UNI/NNI
access channel."
::= { frChanEntry 3 }
frChanContact OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the network
contact for this UNI/NNI access channel."
::= { frChanEntry 4 }
frChanLocation OBJECT-TYPE
SYNTAX DisplayString (SIZE(0..255))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the network
location for this UNI/NNI access channel."
::= { frChanEntry 5 }
frChanIfType OBJECT-TYPE
SYNTAX INTEGER {
uni(1),
nni(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the type of
network interface for this access channel."
::= { frChanEntry 6 }
T. Cox (editor) Expires 12/31/93 [Page 19]
Internet Draft Frame Relay Service MIB May 12, 1993
frChanIfSpecific OBJECT-TYPE
SYNTAX OBJECT IDENTIFIER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is the OID for the MIB
directly below the Frame Relay Layer for this
access channel. This MIB, for example, may be the
DS1 MIB or the ATM MIB."
::= { frChanEntry 7 }
frChanQ922AddLen OBJECT-TYPE
SYNTAX INTEGER {
twoOctets(1),
threeOctets(2),
fourOctets(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the address
length for frame relay frames for this access
channel."
::= { frChanEntry 8 }
frChanDLCILen OBJECT-TYPE
SYNTAX INTEGER {
tenBits(1),
sixteenBits(2),
seventeenBits(3),
twentyThreeBits(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the DLCI
length for frame relay frames for this access
channel."
::= { frChanEntry 9 }
frChanSigState OBJECT-TYPE
SYNTAX INTEGER {
ccittQ933A(1),
ansiT1617D(2),
lmi(3),
T. Cox (editor) Expires 12/31/93 [Page 20]
Internet Draft Frame Relay Service MIB May 12, 1993
q933AnsiT1617B(4),
none(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Local
In-Channel Signaling Protocol that is used for
this access channel."
::= { frChanEntry 10 }
frChanSigProced OBJECT-TYPE
SYNTAX INTEGER {
u2nuser(1),
u2nnet(2),
bidirect(3)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Local
In-Channel Signaling Procedure that is used for
this access channel. The access channel can be
performing user-to-network user-side procedures,
user-to-network network-side procedures, or
bidirectional procedures."
::= { frChanEntry 11 }
frChanSigUserN391 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the User-side
N391 value for this access channel. If the access
channel is not performing user-side procedures,
then this value is zero."
DEFVAL { 6 }
::= { frChanEntry 12 }
frChanSigUserN392 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
T. Cox (editor) Expires 12/31/93 [Page 21]
Internet Draft Frame Relay Service MIB May 12, 1993
"The value of this object identifies the User-side
N392 value for this access channel. If the access
channel is not performing user-side procedures,
then this value is zero."
DEFVAL { 3 }
::= { frChanEntry 13 }
frChanSigUserN393 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the User-side
N393 value for this access channel. If the access
channel is not performing user-side procedures,
then this value is zero."
DEFVAL { 4 }
::= { frChanEntry 14 }
frChanSigUserT391 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the User-side
T391 value for this access channel. If the access
channel is not performing user-side procedures,
then this value is zero."
DEFVAL { 10 }
::= { frChanEntry 15 }
frChanSigNetN392 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Network-
side N392 value for this access channel. If the
access channel is not performing network-side
procedures, then this value is zero."
DEFVAL { 3 }
::= { frChanEntry 16 }
frChanSigNetN393 OBJECT-TYPE
SYNTAX INTEGER (0..20)
T. Cox (editor) Expires 12/31/93 [Page 22]
Internet Draft Frame Relay Service MIB May 12, 1993
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Network-
side N393 value for this access channel. If the
access channel is not performing network-side
procedures, then this value is zero."
DEFVAL { 4 }
::= { frChanEntry 17 }
frChanSigNetT392 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Network-
side T392 value for this access channel. If the
access channel is not performing network-side
procedures, then this value is zero."
DEFVAL { 15 }
::= { frChanEntry 18 }
frChanSigNetnN4 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Network-
side nN4 value for this access channel. If the
access channel is not performing network-side
procedures or is not performing lmi procedures,
then this value is zero."
::= { frChanEntry 19 }
frChanSigNetnT3 OBJECT-TYPE
SYNTAX INTEGER (0..20)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the Network-
side nT3 value for this access channel. If the
access channel is not performing network-side
procedures or is not performing lmi procedures,
then this value is zero."
::= { frChanEntry 20 }
T. Cox (editor) Expires 12/31/93 [Page 23]
Internet Draft Frame Relay Service MIB May 12, 1993
-- the Frame Relay Channel Errors
frChanErrorsTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrChanErrorsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The Frame Relay Channel Errors table."
::= { frnetserv 2 }
frChanErrorsEntry OBJECT-TYPE
SYNTAX FrChanErrorsEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the Frame Relay Channel Errors
table."
INDEX { frChanErrorsIfIndex }
::= { frChanErrorsTable 1 }
FrChanErrorsEntry ::=
SEQUENCE {
frChanErrorsIfIndex
INTEGER,
frChanErrorsTooLongFrames
Counter,
frChanErrorsCRCErrors
Counter,
frChanErrorsHDLCAborts
Counter,
frChanErrorsSigLinkRelRespErrors
Counter,
frChanErrorsSigProtRespErrors
Counter,
frChanErrorsSigInactiveResps
Counter,
frChanErrorsSigLinkRelInitErrors
Counter,
frChanErrorsSigProtInitErrors
Counter,
frChanErrorsSigInactiveInits
Counter
}
frChanErrorsIfIndex OBJECT-TYPE
T. Cox (editor) Expires 12/31/93 [Page 24]
Internet Draft Frame Relay Service MIB May 12, 1993
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to MIB II's
ifIndex value for this UNI/NNI access channel."
::= { frChanErrorsEntry 1 }
frChanErrorsTooLongFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frame relay frames received that
were too long for this UNI/NNI access channel."
::= { frChanErrorsEntry 2 }
frChanErrorsCRCErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frame relay frames received that
had CRC errors for this UNI/NNI access channel."
::= { frChanErrorsEntry 3 }
frChanErrorsHDLCAborts OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frame relay HDLC frames received
that were aborted for this UNI/NNI access
channel."
::= { frChanErrorsEntry 4 }
frChanErrorsSigLinkRelRespErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of local in-channel signaling link
reliability errors that were responding to polls
for this UNI/NNI access channel."
::= { frChanErrorsEntry 5 }
T. Cox (editor) Expires 12/31/93 [Page 25]
Internet Draft Frame Relay Service MIB May 12, 1993
frChanErrorsSigProtRespErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of local in-channel signaling protocol
errors that were responding to polls for this
UNI/NNI access channel."
::= { frChanErrorsEntry 6 }
frChanErrorsSigInactiveResps OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times the channel declared inactive
responding to polls (i.e., N392 errors in N393
events) for this UNI/NNI access channel."
::= { frChanErrorsEntry 7 }
frChanErrorsSigLinkRelInitErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of local in-channel signaling link
reliability errors that were initiating polls for
this UNI/NNI access channel."
::= { frChanErrorsEntry 8 }
frChanErrorsSigProtInitErrors OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of local in-channel signaling protocol
errors that were initiating polls for this UNI/NNI
access channel."
::= { frChanErrorsEntry 9 }
frChanErrorsSigInactiveInits OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
T. Cox (editor) Expires 12/31/93 [Page 26]
Internet Draft Frame Relay Service MIB May 12, 1993
"The number of times the channel declared inactive
initiating polls (i.e., N392 errors in N393
events) for this UNI/NNI access channel."
::= { frChanErrorsEntry 10 }
T. Cox (editor) Expires 12/31/93 [Page 27]
Internet Draft Frame Relay Service MIB May 12, 1993
-- The Frame Relay PVC Group
-- Implementation of this group is mandatory for all systems
-- that perform Frame Relay Services.
-- the Frame Relay PVC Information
frPVCTable OBJECT-TYPE
SYNTAX SEQUENCE OF FrPVCEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"The Frame Relay PVC table."
::= { frnetserv 3 }
frPVCEntry OBJECT-TYPE
SYNTAX FrPVCEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the Frame Relay PVC table."
INDEX { frPVCIfIndex, frPVCDLCIIndex }
::= { frPVCTable 1 }
FrPVCEntry ::=
SEQUENCE {
frPVCIfIndex
INTEGER,
frPVCDLCIIndex
INTEGER,
frPVCLocalOrient
INTEGER,
frPVCRemoteIfIndex
INTEGER,
frPVCRemoteDLCIIndex
INTEGER,
frPVCRemoteNetAddress
OCTET STRING,
frPVCAdminStatus
INTEGER,
frPVCOperStatus
INTEGER,
frPVCSegmentNumber
INTEGER,
frPVCRcvdSigStatus
T. Cox (editor) Expires 12/31/93 [Page 28]
Internet Draft Frame Relay Service MIB May 12, 1993
INTEGER,
frPVCAccountUnitSize
INTEGER,
frPVCInFrames
Counter,
frPVCOutFrames
Counter,
frPVCOutAccUnits
Counter,
frPVCBcDiscardState
INTEGER,
frPVCBcDiscardStateTimes
Counter,
frPVCFwdBc
INTEGER,
frPVCFwdBe
INTEGER,
frPVCFwdCIR
INTEGER,
frPVCBwdBc
INTEGER,
frPVCBwdBe
INTEGER,
frPVCBwdCIR
INTEGER,
frPVCMaxFrameSize
INTEGER
}
frPVCIfIndex OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to MIB II's
ifIndex value for this UNI/NNI access channel."
::= { frPVCEntry 1 }
frPVCDLCIIndex OBJECT-TYPE
SYNTAX INTEGER (1..8388608)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the DLCI
value for this UNI/NNI access channel - PVC pair."
T. Cox (editor) Expires 12/31/93 [Page 29]
Internet Draft Frame Relay Service MIB May 12, 1993
::= { frPVCEntry 2 }
frPVCLocalOrient OBJECT-TYPE
SYNTAX INTEGER {
originating(1),
terminating(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object provides the orientation
of this PVC through the network for this UNI/NNI
access channel - PVC pair. This information helps
to determine which direction is forward and
backwards; originating to terminating is forwards,
and terminating to originating is backwards."
::= { frPVCEntry 3 }
frPVCRemoteIfIndex OBJECT-TYPE
SYNTAX INTEGER (1..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to MIB II's
ifIndex value for the remote UNI/NNI access
channel."
::= { frPVCEntry 4 }
frPVCRemoteDLCIIndex OBJECT-TYPE
SYNTAX INTEGER (1..8388608)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the DLCI
value for the remote UNI/NNI access channel - PVC
pair."
::= { frPVCEntry 5 }
frPVCRemoteNetAddress OBJECT-TYPE
SYNTAX OCTET STRING (SIZE(0..8))
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the remote
UNI/NNI access channel."
T. Cox (editor) Expires 12/31/93 [Page 30]
Internet Draft Frame Relay Service MIB May 12, 1993
::= { frPVCEntry 6 }
frPVCAdminStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
inactive(3),
testing(4),
notInService(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
administrative status of this UNI/NNI access
channel - PVC pair."
::= { frPVCEntry 7 }
frPVCOperStatus OBJECT-TYPE
SYNTAX INTEGER {
up(1),
down(2),
inactive(3),
testing(4),
notInService(5)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the
operational status of this UNI/NNI access channel
- PVC pair."
::= { frPVCEntry 8 }
frPVCSegmentNumber OBJECT-TYPE
SYNTAX INTEGER (1..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the PVC
segment number for this PVC segment for this
UNI/NNI access channel - PVC pair. As a PVC
traverses multiple networks, each PVC segment
(i.e., each network) will be numbered starting
with the first network in the forward direction.
T. Cox (editor) Expires 12/31/93 [Page 31]
Internet Draft Frame Relay Service MIB May 12, 1993
The numbering should start at one and go to N,
where N is the Nth network in the chain."
::= { frPVCEntry 9 }
frPVCRcvdSigStatus OBJECT-TYPE
SYNTAX INTEGER {
active(1),
inactive(2),
deleted(3),
none(4)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the PVC
status received via the local in-channel signaling
procedures for this UNI/NNI access channel - PVC
pair. This object is only is only pertinent for
bidirectional procedures and user-to-network user
side procedures. For user-to-network network side
procedures, the value of this object should be
none."
::= { frPVCEntry 10 }
frPVCAccountUnitSize OBJECT-TYPE
SYNTAX INTEGER (1..255)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies the the
accounting unit size for this UNI/NNI access
channel - PVC pair. The accounting unit size is
equal to a block of octets."
::= { frPVCEntry 11 }
frPVCInFrames OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames received for this UNI/NNI
access channel - PVC pair."
::= { frPVCEntry 12 }
frPVCOutFrames OBJECT-TYPE
T. Cox (editor) Expires 12/31/93 [Page 32]
Internet Draft Frame Relay Service MIB May 12, 1993
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of frames sent for this UNI/NNI access
channel - PVC pair."
::= { frPVCEntry 13 }
frPVCOutAccUnits OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of accounting units sent for this
UNI/NNI access channel - PVC pair."
::= { frPVCEntry 14 }
frPVCBcDiscardState OBJECT-TYPE
SYNTAX INTEGER {
yes(1),
no(2)
}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object identifies whether this
UNI/NNI access channel - PVC pair is in a Bc
discard state."
::= { frPVCEntry 15 }
frPVCBcDiscardStateTimes OBJECT-TYPE
SYNTAX Counter
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The number of times this UNI/NNI access channel -
PVC pair has been in a Bc discard state."
::= { frPVCEntry 16 }
frPVCFwdBc OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the forward
T. Cox (editor) Expires 12/31/93 [Page 33]
Internet Draft Frame Relay Service MIB May 12, 1993
Bc for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 17 }
frPVCFwdBe OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the forward
Be for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 18 }
frPVCFwdCIR OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the forward
CIR for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 19 }
frPVCBwdBc OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the backward
Bc for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 20 }
frPVCBwdBe OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the backward
Be for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 21 }
frPVCBwdCIR OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the backward
T. Cox (editor) Expires 12/31/93 [Page 34]
Internet Draft Frame Relay Service MIB May 12, 1993
CIR for this UNI/NNI access channel - PVC pair."
::= { frPVCEntry 22 }
frPVCMaxFrameSize OBJECT-TYPE
SYNTAX INTEGER (0..4294967295)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"The value of this object is equal to the maximum
frame size for this UNI/NNI access channel - PVC
pair."
::= { frPVCEntry 23 }
END
T. Cox (editor) Expires 12/31/93 [Page 35]
Internet Draft Frame Relay Service MIB May 12, 1993
7. Acknowledgments
This document was produced by the Frame Relay Service MIB
Working Groups:
Special thanks goes to the Frame Relay Forum Technical
Committee for its participation in writing this MIB.
T. Cox (editor) Expires 12/31/93 [Page 36]
Internet Draft Frame Relay Service MIB May 12, 1993
8. References
[1] Cerf, V., "IAB Recommendations for the Development of Internet
Network Management Standards", RFC 1052, NRI, April 1988.
[2] Cerf, V., "Report of the Second Ad Hoc Network Management
Review Group", RFC 1109, NRI, August 1989.
[3] Rose M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[4] McCloghrie K., and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets", RFC 1156, Hughes
LAN Systems, Performance Systems International, May 1990.
[5] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", RFC 1157, SNMP Research,
Performance Systems International, Performance Systems
International, MIT Laboratory for Computer Science, May 1990.
[6] McCloghrie K., and M. Rose, Editors, "Management Information
Base for Network Management of TCP/IP-based internets", RFC 1213,
Performance Systems International, March 1991.
[7] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization, International
Standard 8824, December 1987.
[8] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Notation One
(ASN.1), International Organization for Standardization,
International Standard 8825, December 1987.
[9] Rose, M., and K. McCloghrie, Editors, "Concise MIB Definitions",
RFC 1212, Performance Systems International, Hughes LAN Systems,
March 1991.
T. Cox (editor) Expires 12/31/93 [Page 37]
Internet Draft Frame Relay Service MIB May 12, 1993
9. Security Considerations
Security issues are not discussed in this memo.
10. Authors' Addresses
Tracy A. Cox
Bell Communications Research
331 Newman Springs Road
P.O. Box 7020
Red Bank, NJ 07701-7020
Phone: (908) 758-2107
EMail: tacox@mail.bellcore.com
T. Cox (editor) Expires 12/31/93 [Page 38]
Internet Draft Frame Relay Service MIB May 12, 1993
Table of Contents
1 Status of this Memo ................................... 1
2 Abstract .............................................. 1
3 The Network Management Framework ...................... 2
4 Objects ............................................... 3
4.1 Format of Definitions ............................... 3
5 Overview .............................................. 4
5.1 Apply MIB II to a Frame Relay Service ............... 5
5.2 Apply the DS1/E1 MIB to Frame Relay Service ......... 7
5.3 Frame Relay Service MIB Terminology ................. 11
6 Object Definitions .................................... 16
6.1 The Frame Relay Service Channel Group ............... 17
6.1.1 The Frame Relay Channel Information ............... 17
6.1.2 The Frame Relay Channel Errors .................... 24
6.2 Frame Relay PVC Group ............................... 28
7 Acknowledgments ....................................... 36
8 References ............................................ 37
9 Security Considerations ............................... 38
10 Authors' Addresses ................................... 38
T. Cox (editor) Expires 12/31/93 [Page 39]